Thank you for checking, @Bodigrim.

@geekosaur maybe we should do this routinely when updating bounds to our dependencies.

Probably yes; I forgot this time. I wonder if there's some way to automate this (we already have the appropriate inputs, but they can only be used with workflow_dispatch). Maybe a label, but then we need some way to pass it the appropriate inputs.

Can we backport this to 3.16?

@mergify backport 3.16

backport 3.16

✅ Backports have been created

@bgamari is it necessary for the GHC 9.14 release? we planned a release of cabal only after 9.14 is out

@bgamari is it necessary for the GHC 9.14 release? we planned a release of cabal only after 9.14 is out

Yes it is.

Perhaps more to the point: is this needed for the alpha? I think the original plan was to test against the alpha and fix anything else needed for it to work. Failing that, we should at least have a branch to test against.

I first thought we might need another release, but that's not necessarily the case: a revision of 3.16.0.0 (which, the release, is already on Hackage), hopefully, would be enough? @bgamari

Except that libraries/Cabal is bundled with ghc, so that probably needs to have an updated cabal file. Especially if it's expected to build with the bundled libraries/time.

As @geekosaur said, GHC needs an upstream git commit as Cabal is a boot library included in the GHC tree via submodule. Moreover, ideally a revision should not pushed to Hackage until the corresponding commit is committed to the appropriate release branch.

Regardless, the backport has happened in #11137 so I don't think anything more is needed here.

mergify backport 3.14

I'm requesting the backport due to commercialhaskell/stackage#7919.

@mergify backport 3.14

backport 3.14

✅ Backports have been created